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(54) Telecommunications network management 

(57) A telecommunications network management system has a database DB including information about the 
network, the information being in the form of objects that relate to the network elements to be managed by 
one or more operatives running applications APPLN at system parts PP1 ... PPN peripheral to a core part CP. In 
order to reduce the required bandwidth between applications APPLN and the core part CP, an object selection 
procedure using a set of Attribute Value Assertions (AVAs) is effected at a selection point so that only certain 
objects will be selected. Each AVA comprises an attribute identifier, a value, and an operation. For each AVA, 
the attribute identifier is used to obtain the value of this attribute for the object subject to selection, and the 
AVA operation is applied to this value and the value in the AVA to obtain an intermediate result. The 
intermediate results for the set of AVAs are logically combined to obtain a final result, and the object is 
selected or not selected on the basis of this final result. A similar operation using AVAs may be used for 
filtering the passage of events. 
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Telecommunications network management method 

The present invention relates to a management 
method according to the preamble of the attached claim 
1 for managing a telecommunications network. The 
telecommunications network to be managed may be e.g. a 
SDH (Synchronous Digital Hierarchy) network, a PDH 
(Plesiochronous Digital Hierarchy) network, or a 
combination of such networks . 

The basic situation in network management is 
usually such that an operator managing a telecom- 
munication networks, e.g. a telephone company, has a 
plurality of customers (i.e, network users) in addi- 
tion to the physical network. The operator sells the 
customers various services that utilize the network. 
(A public network will be used herein as an example; 
in principle, however, the same description applies to 
a private operator managing e.g. an organization 
network). To meet customers' data transmission 
requirements in the physical network, the operator 
utilizes a number of facilities or operative processes 
for the provision of customer services. These oper- 
ative processes can be divided into groups in accord- 
ance with the functions for which they are intended: 

Service Provisioning taking care of the 
performance of customer services, including e.g. 
invoicing customers for services. 

- Operation & Maintenance for keeping the net- 
work operative to allow the usage of customer 
services. One of the most important functions in this 
respect is the supervision and repair of network 
faults . 

- Planning & Development, the function of which 
is to develop network operation so as to better meet 




2 

customers' needs and to increase the overall 
profitability of the operator enterprise. 

As appears from the above, network management 
takes place on several different levels, depending on 
5 the extent to which the functions to be performed on a 
specific level are associated with the overall manage- 
ment of the operator enterprise. The management of a 
telecommunications network is generally divided into 
four different levels, which are from bottom to top as 
10 follows: 

- network element management layer, 

- network management layer, 

- service management layer, and 

- business management layer. 

15 This division is used e.g. in the ITU-T (the 

former CCITT) recommendation M.3010, which specifies a 
kind of framework for the management architecture of a 
telecommunications network. The bottom layer below the 
above four layers is the equipment itself; these 

20 equipments are managed by installation and field 
engineering tools. 

The network element management layer means the 
management of an individual network element (such as a 
multiplexer or a cross-connection device) as a separ- 

25 ate component without simultaneously paying attention 
to the condition of the network or other network 
elements. The majority of so called -network mana- 
gement" systems commercially available today are actu- 
ally network element management systems within this 

30 layer. 

The network management layer is concerned with 
the management of the entire telecommunications net- 
work, such as overall management of network con- 
nections. One example is the creation of connections 
35 and the end-to-end supervision of their condition. 
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This means that e.g. alarms detected on equipment are 
not just displayed against that equipment, but they 
are also propagated to show what services (paths and 
circuits) are affected by the fault, if any. The 
present invention is positioned in this layer. 

As distinct from the above, the service manage- 
ment layer is not concerned with technical network 
management. It takes care of e.g. customer data, 
supervision of services provided to customers, invoic- 
ing for services, euid considering needs for services 
of different types. 

The business management layer is used to monitor 
and plan the business activities and economy of the 
entire enterprise, resulting in decisions affecting 
the lower levels. 

At present, network management systems are 
changing into systems that manage the telecommuni- 
cations network as a whole, whereas conventional 
management systems have handled only the remote 
control of transmission equipment, especially monitor- 
ing alarms produced by the equipment. In conventional 
network management methods, configuration changes, 
such as creation of new end-to-end connections, have 
been laborious and time-consuming, as the end result 
consists of several configuration events the pre- 
requisite of which is that the maintenance staff of 
the network first gets an overall view of the situ- 
ation and then decides on configuration changes 
required in individual network elements. In new 
network management systems, on the contrary, an 
overall view of the network and its condition is 
produced within the system, and the system itself 
gives the required configuration commands to each 
transmission equipment. As a consequence, all con- 
figuration changes can be performed significantly more 



rapidly than previously. Such developments have been 
accelerated by the freeing of competition in the field 
of telecommunications . 

The above-mentioned recommendation M.3 010 
specifies the management architecture as shown in 
Figure 1. The architecture basically consists of one 
or more operations systems OS connected to a data 
communication network DCN communicating with an actual 
telecommunications network which is to be managed and 
which includes the network elements NE managed. It is 
to be noted that the connections of the data 
communications network and those of the 
telecommunications network are logically distinct, 
although they can be implemented physically in one and 
the same cable. Logically, there are thus two 
networks: {a) a network providing services to 
customers, euid (b) a network maintaining the service 
provisioning network. The management of certain 
transmission equipments (network elements) further 
requires a separate Mediation Device MD, which mainly 
acts as a protocol converter between a Q3 interface 
complying with the recommendations and transmission 
equipments that do not understand the protocol applied 
in the interface but use their own proprietary 
protocol. New SDH equipment, for instance, can be 
connected directly to the Q3 interface, whereas older 
PDH equipment requires a Mediation Device. 

In practice, a management network for a combined 
SDH and PDH network may be e.g. such as shown in 
Figure 2. Users (network operator staff) sitting at 
the operation centre use network management work 
stations WS connected to a separate local area network 
WSN, which may be e.g. an Ethernet network. The 
management system is typically distributed in several 
computers of the local area network, one of the 



computers being a dedicated application server SRV 
having a database DB containing information necessary 
for managing the network. In its practical embodiment, 
the local area network further comprises e.g. 
necessary back-up devices (like DAT drives or mirrored 
disks) and event-logging printers (not shown) . 

The management system is connected via the 
above-mentioned Q3 interface e.g. to the SDH network. 
A variety of alternatives have been defined for the Q3 
interface, so that the interface may be e.g. an X.2 5 
type packet switched interface or an Ethernet LAN 
interface. (The packet switched interface is useful if 
the operator in charge of the network management also 
otherTvise uses a packet switched network.) in 
practice, control channels between the SDH network 
elements 21 are established in the overhead bytes of 
the STM-N signal (N = 1, 4, 16), so that control 
signals between SDH equipments propagate with the 
payload signal (that is, also in the same physical 
network) . Such control channels established in the 
overhead bytes are called Embedded Control Channels, 
and they are formed e.g. in the STM-1 frame by the 
section overhead bytes Dl to D12 . 

PDH equipments, on the contrary, need 
manufacturer-specific solutions, wherefore they have 
to be connected to the management system through a 
separate mediation device 22. 

The management system may also be hierarchical 
so that different geographical areas have their own 
smaller management systems that together form an 
integral management network- For instance, a 
management system covering one country may be divided 
geographically into smaller management systems 
operating in different parts of the country. Each 
smaller management system takes care of the management 




of the network portion in the concerned geographical 
area. In the example of Figure 2, management systems 
MSI and MS2 geographically apart from each other form 
together a single common management system and 
5 management network. 

Network management standards are nowadays 
largely based on so-called object-oriented 
descriptions, though the standards do not require the 
use of this technique. Objects are data structures in 

10 a network management system, which describe the 
functions and state of a network component . An obj ect 
is thus an element having certain attributes ("I am 
like this") and certain operations ("I can do these 
things"). (In the object-oriented approach, objects 

15 with the same data structure (attributes) and the same 
behaviour (operations) are grouped into a class. A 
specific implementation of an operation is called a 
method and each object is said to be an instance of 
its class.) A typical object is e.g. a cross- 

20 connection device with certain attributes (cross- 
connections that are active) and certain methods (e.g. 
make cross-connection and release cross-connection) . 

In a telecommunications network management 
system, objects can be physical ones or logical ones. 

25 Physical objects are elements that form part of the 
physical network. Such objects are e.g. the above- 
mentioned network elements (a network element is any 
piece of telecommunication equipment that works as a 
single unit to provide telecommunication functions) or 

30 physical connections (such as optical fibres, twisted 
pair cables, coaxial cables, radio links or satellite 
links) . Logical objects are logical entities that do 
not fo3nn a single piece of the physical network. Such 
objects are e.g. paths and circuits. (A path is a 

35 connection of a fixed bit rate and format between two 
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physical interfaces within the network. A circuit is 
connection set up for a customer, between two physical 
interfaces on the boundary of the network. Thus, 
circuit usually comprises several consecutive paths.) 
5 A network object may have a number of different 

attributes. Some attributes (such as "fault state") 
are used by several different types of object. In 
addition, for some types of network object (such as a 
route), it is convenient to define an attribute which 
10 consists of a collection of other attributes. Typical 
attributes are e.g. "availability status", "fault 
state" and "operational state". The attributes have 
different possible values, e.g. "fault state" can have 
values : 

15 - OK. There are no problems. 

- Warning. There are outstanding faults, but 
these do not effect services. 

- Degraded. Some or all of the services provided 
by the object are degraded. 

■ Failed. All the services provided by the 
object are lost. 

- Unknown. The fault state of the object is 
unknown . 

The "operational state", in turn, can have e.g. 
25 two different values: 

- Enabled. The object can operate, either 
completely or in part. 

- Disabled. The object cannot operate at all. 
Thus, objects are used to represent the 

30 fundamental items with which the management system 
works, e.g. network elements, paths and users. To be 
able to examine the objects and to perform operations 
on them, the management system needs to obtain copies 
of these objects from the persistent storage. The 

35 objects can be fetched by their internal unique 
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identifier if this is known, or by performing a search 
of the objects using search criteria which define a 
group of conditions which an object must match to be 
selected. 

5 Also within the network management system 

events are passed around to various processes An 
event may originate from e.g. from the network to be 
managed or it may occur as a result of the user 
actions, e.g. when the user gives a command from the 
10 workstation. To contain the number of events being 
passed, they are only passed on at each stage if some 
process in the system has indicated that it wishes to 
receive them. This wish to receive certain events is 
indicated by registering filters which specify the 
criteria which an event must match to be selected and 
hence passed on. (The selection mechanism using 
filters is identical to that used for selecting 
objects in searches.) 

Thus, filtering/selecting is a way of specifying 
the information you are interested in. 

In a network management system the criteria 
which can be used for filtering (and the attributes 
searched for) evolve over time, as different objects 
are included in the system (as a result of e.g 
changes in the network to be managed) . Therefore, the 
problem relating to filtering is how to get a method 
which allows new type of data and new type of objects 
to be added easily in the system, without effecting 
the ability to apply all filters to all objects and 
30 all events. The possibility to apply all filters to 
all objects should remain even if the objects do not 
have the attributes which are being filtered upon. 

These goals are achieved by means of the method 
according to the invention, which is, in its first 
35 embodiment characterized by what is set forth in the 
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characterizing portion of the attached claim 1, and in 
its second embodiment by what is set forth in the 
characterizing portion of the attached claim 4. 

The idea of the present invention is to find at 
a selection/ filtering point of the system the value of 
an attribute in an obj ect /event , apply a predetermined 
stored operation to that value and another value which 
is stored in the system, and evaluating the result. 
The above steps are repeated as many times as the 
stored filtering information shows and the results are 
then combined, using the stored filtering information, 
to get a final result for the filter. The final result 
determines whether the event is filtered (or the 
object selected) . 

Thanks to the solution according to the present 
invention, filtering can be applied to any object 
without euiy special knowledge of the type or 
attributes of the object to be filtered. The method is 
also generic, extensible and typesafe, i,e. it can use 
the comparisons appropriate for the attribute being 
filtered and copes with objects not containing that 
attribute. 

Below, the invention and its preferred 
embodiments will be described in greater detail with 
reference to the examples of figures 4 to 5 of the 
attached drawings, in which 

Figure 1 illustrates a telecommxinications 
network management architecture. 

Figure 2 shows an example of a management 
network for a combined SDH and PDH network. 

Figure 3 illustrates the functional architecture 
of the management system according to the present 
invention in its basic form; 

Figure 4 illustrates implementation of generic 
values , 



Figure 5 is a flovj chart describing how a filter 
is applied to searching for objects from the database. 

Figure 6 is a flow chart which illustrates 
evaluating an AVA. 

Figure 7 illustrates the method according to the 
invention when a filter is applied to an object which 
it matches, and 

Figure 8 illustrates the method according to the 
invention when a filter is applied to an object which 
it does not match. 

The management system shown in Figure 3 will 
first be referred to, the system having such a 
functional architecture that the greatest possible 
benefit will be derived from filtration. A system with 
this kind of architecture is able to operate e.g. in 
the system shown in Figure 2. The system comprises a 
single core part CP and one or more peripheral parts 
PP1...PPN, which are connected to the core part of the 
system. In this example, each peripheral part is 
intended for one user (operator employee) of the 
system. 

The system typically has a dedicated core com^ 
puter, such as a server SRV {also shown in Figure 2). 
The core part of the system keeps up an updated model 
of the state and operation of the telecommunications 
network TN to be meoiaged, of which a single network 
element is shown in the figure. As described earlier, 
the core part uses objects to keep up this model. The 
core computer SRV is connected to one or several work- 
stations WS1...WSN each including one peripheral part. 
The functional processes of the system, which run on 
the core computer and on the workstations, have been 
marked with ovals. These processes will be described 
in the following. 

An application (indicated with the references 
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APPLN1...APPLN4 in Figure 3) is a functional system 
block which allows the user to configure the network 
and view network events on the screen of the work- 
station. The application is thus a system part offer- 
ing the system's services to the user. An individual 
workstation is therefore also called an application 
server . 

A Session Handler SH is a functional system part 
that handles a single user's session with the system 
and forwards messages between the core and the user's 
applications. The Session Handler can be associated 
with the initial system log-on window through which a 
user logs on and establishes a session with the core. 
The Session Handler starts up various applications 
according to commands given by the user. When the user 
logs out, the Session Handler performs the necessary 
closing-down and deregistering operations to terminate 
the session (the term registering will be explained 
later) . 

^° ^ Access Process CAP verifies that the 

Session Handler belongs to a known user on a known 
host. Having done so, it acts as the gateway to the 
system core. For each CAP in the core part there is a 
corresponding Session Handler in the peripheral part. 

^ Database Process DP controls access to the 
database DB to store persistent information (master 
objects of the management system) . The main function- 
ality of this process is: 

- to convert persistent objects to and from a 
30 storable format, 

- to store the current state of all persistent 
objects in the database DB and to keep that database 
up to date by the use of change and event messages 
sent to it by a Modelling Process MP of the core part, 

- to handle the forwarding of event information 
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to interested parts of the system. 

The Modelling Process MP is responsible for 
maintaining the currency of the core's model of the 
network to be managed and dealing with changes to it. 
The main functions of the Modelling Process are: 

- to accept change and event indications from 
either Interface Process IP or CAP (i.e. either from 
the network or from the user) and validate them, 

- to apply changes to the model if they are 
valid and to determine the results of these changes, 

to pass the changes to an appropriate 
Interface Process IP, if the changes require corre- 
sponding changes in the network to be managed, 

- to generate events based on the changes and 
events received (e.g. fault events on paths and cir- 
cuits) . 

The Interface Process IP is a functional system 
part that converts data from the external world (data 
from the network to be managed) into the internal 
world of the management system. As far as the system 
user is concerned, he or she just sees a network 
element NE, like a multiplexer or a cross-connect 
device, without having to know the manufacturer or the 
version of the device. Different types of Interface 
Processes are used for different classes of equipment. 
The main functionality of each IP is: 

to monitor the network for events and to 
exchange notifications with the network, 

- to translate these events and notifications 
into equivalent events that are applied to the 
Modelling Process MP, 

- to pass these events and notifications to the 
Modelling Process, 

- to accept changes received from the Modelling 
Process; translate them into the format of the network 



model; and send them to the network and then inform 
the Modelling Process when all commands relating to 
each original change have succeeded, failed or timed 
out. 

In fact, the Interface Processes could also be 
included in the core part, but Figure 3 shows them 
separate, as they form the interface of the management 
system with the external world. 

A Fault Propagation Agent Process FPAP is a 
functional system part that works out the actual 
impact of a received event in the system. In order to 
be able to do this the FPAP uses information about the 
object class in question. This information it receives 
from the Database Process DP. 

As the network elements cannot provide all the 
information needed by the applications, the database 
DB must store information e.g. about individual net- 
work elements and interconnections and interrelations 
between the network elements, the operations the net- 
work elements are capable of performing, and the ser- 
vices provided by the network elements. This informa- 
tion is stored in the form of an object model repre- 
senting the transmission network TN in terms of 
objects and their attributes and methods performed on 
these attributes. Thus, an object is the representa- 
tion, in the object model, of one of the resources to 
be managed. 

Applications use these objects that form the 
image of the network to be managed within the system. 
Therefore, they have to get objects from the core part 
of the system. An application can also create a new 
core object to database DB, e.g. as a result of a user 
command. 

Applications also register to receive various 
events. The registration is passed to the Session 
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Handler and further to the core part of the system. 
The registration is stored in the form of a filter Fl 
in association with the Database Process DP. This 
filter finds out on the basis of the event type, to 
which Core Access Processes and to which applications 
a certain type of event is to be transmitted (i.e. 
what users are interested in a certain type of event) . 
Events from the core of the system are duplicated in 
the Session Handler and sent to all applications which 
have registered to receive them. In this way. all of 
the user's applications can receive the event at the 
same time, so that information presented to the user 
by the different applications is consistent. 

In this way the core part of the system knows to 
which application a certain event has to be trans- 
mitted. This also allows \inwanted events to be filter- 
ed out as soon as possible (in the core) and reduces 
the bandwidth used between applications and the core 
part of the system. The core part is thus able to 
filter events up to the application level. It is also 
possible to use filters in steps so that the core part 
Icnows only up to the level of the Session Handler what 
event has to be transmitted to the peripheral part. 
The Session Handler thereafter has a new filter, which 
indicates in which event a specific application inside 
the concerned Session Handler is interested. The first 
alternative, however, is to be preferred in that it 
does not make the peripheral part (Session Handler) 
too complicated. 

In the management system of Figure 3, part of 
the objects stored in the core part of the management 
system are also placed as copies in a cache CH at each 
Session Handler SH. (Although a cache is a certain 
kind of memory, in this connection caching means only 
that a copy of something is kept to get fast access to 
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it.) Thus, the Session Handler has a copy of any 
object an application has fetched from the core part 
of the system. The Session Handler thus also stores 
object-specific information indicating which one of 
its applications uses a specific object. This 
information can be stored e.g. in the form of a table 
TBLl shown in Figure 3 . The core part correspondingly 
knows which Session Handler has a copy of a specific 
master object. This information can be stored in the 
form of a table TBL2 in association with the Database 
Process . 

At the system start-up, the Session Handler has 
no copies of objects. When the application needs a 
copy for the first time, the copy is fetched from the 
core part. As the transmitted retrieve message 
includes information specifying the object to be 
retrieved and the application that needs the copy, the 
Session Handler is able to keep up a table (TBLl) 
indicating which application uses a specific object, 
and the Database Process is able to keep up a table 
indicating which Session Handler uses a copy of a 
specific master object. 

If an application fetches an object of which the 
Session Handler already has a copy, the application 
receives a copy of the object from the Session Handler 
without having to interact with the core part of the 
system. When the application ceases using an object, 
it transmits a message as an indication of this to the 
core part through the Session Handler, as a result of 
which the copy is removed from the memory of the Ses- 
sion Handler and the tables are updated accordingly. 
If the object is needed again, the copy is fetched 
from the core in the same way as at the system start- 
up. 

When changes are made to an object in an 
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application, the Session Handler immediately com- 
municates them to all other applications in the 
session that use said object. (The Session Handler 
receives information on the change from the 
application making the change, updates its own copy, 
and passes the events to all other applications using 
said object.) These changes are also transmitted 
through the Session Handler to the core, which 
reapplies the changes to the master objects to keep 
the state of the master copies consistent with the 
state of the copies in the peripheral part. 

A system architecture of the type described 
above is described in the Applicant's parallel patent 
application GB-A-XXXX, which is referred to for a more 
detailed description. This application describes e.g. 
the operation of the different processes more fully. 

The present invention relates to the operation 
of filters (like filter Fl in the above described 
system) for selecting objects, or for filtering of 
events, in a management system, which was described 
briefly above by means of an exampls. This above- 
described example of the system is advantageous in the 
sense that it allows the bandwidth used between the 
applications and the core part to be reduced 
25 efficiently by filtration. Even though selecting 
objects will be used as an example in the text below, 
it is to be understood that filtering of objects or 
events could equally well be used as an example. 

According to the invention, selection criteria 
used to perform filtering are stored assertions about 
the values of attributes of the objects stored in the 
system. These assertions are data sets which are here 
called as Attribute Value Assertions, abbreviated to 
AVAs. According to the invention, a stored filter is a 
35 collection of AVAs linked together by logical 
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operators (i.e. AND, OR and NOT). 

Each AVA is a data set comprising the following 
three data fields : 

- an attribute identifier, 

- a value, and 

- an operation (e.g. "is equal to", "is greater 
than", etc. ) . 

Figure 5 shows how filters are used to search 
for objects from the database. First a filter to be 
used is created (stage 511) or a previously stored 
filter is retrieved from the database (stage 512) . 
The first object is then retrieved from the database 
(stage 513) and filtering is performed (stage 514). 
Next, it is tested whether the end result is true 
(stage 515) . If so, the object is selected (stage 
517) , if not, the object is discarded (stage 516) . 
Then it is checked whether there are any objects to be 
filtered left (stage 518) . If so, stage 513 is 
returned to, if not, the filtering is stopped (stage 
519) . 

Thus, the filter is first fetched to the 
selection point of the system (if it is not stored 
there), i.e. to the point where selection is 
performed. When a filter is applied to an object 
(stage 514 in Figure 5), the following method steps 
are performed. 

The attribute identifier is first used to get 
the value of that attribute from the object being 
filtered. The operation stored in the AVA is then 
applied to this value and to the value stored in the 
filter. The operation evaluates to a truth value by 
performing the operation on the values. This value 
indicates whether the AVA is true for the value of 
attribute in the object and the stored value. 

If the object does not contain the identified 
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attribute, then the AVA evaluates to false as the 
assertion cannot be true for this object. 

In the above-described manner a truth value 
is obtained for each AVA in the filter. Then, the 
truth values obtained by evaluating each AVA in the 
filter are combined by the logical operators stored in 
the filter to yield a truth value for the whole 
filter. If this final value is true, the object is 
allowed to pass the filter, i.e. the object is 
selected. Otherwise it is filtered (not selected) . 

Thus, within this filtering method the value of 
the attribute in the object being filtered must be 
found and must be compared with the value stored in 
the AVA using the operation stored in the AVA. 

In the following the above-described basic 
principles are explained in a more detailed way by 
means of an example which is a preferred embodiment 
where the values of the attributes are stored in a 
generic form. 

In the management system the definition of each 
type of object describes the attributes within the 
object. (The attributes of an object are defined in 
the object model, i.e. they are part of the class that 
is used to model the object.) The description of each 
attribute contains the following information: 

- an identifier: given an object this identifier 
can be used to find the value of the attribute within 
the object. 

" a type: this may be a simple type such as 
String or Integer, or a complex type such as Set of 
Integers . 

a reference to a ValueMethods object: 
ValueMethods objects (program blocks) are used to 
evaluate AVAs. This reference can be implemented in 
any possible ways, e.g. by means of a pointer word. 
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i.e. a binary number the value of which corresponds to 
the object it is pointing to. 

In the system, the attributes are stored in the 
form of the attribute identifiers which contain the 
type, a unique identifying number forming said 
identifier and said reference to a ValueMethods 
object. Values of the attributes are stored elsewhere, 
as explained later. 

To clarify the concept of description of an 
attribute let us think about a managed network element 
(like a cross-connection device) as an example. A 
network element may contain e.g. a Name attribute. 
This Name attribute would then contain the following 
information : 

- identifier: 1 (if this is the first attribute 
in the object) , 

- type: String, 

ValueMethods object: reference (e.g. a 
pointer) to the String ValueMethods object. 

The value of a specific attribute of a specific 
object can be found by using the object and identifier 
to find out where in the object the attribute is 
stored. For example, to find out the name of a network 
element A: 

- the identifier is taken from the attribute (in 
this example 1) , 

- the first attribute in A is found in generic 

form, 

- the ValueMethods object is found from the 
attribute and used to convert the generic form to a 
String which then gives the name. 

As mentioned above, values of attributes are, 
according to the preferred embodiment of the 
invention, stored in generic form. This means that all 
values are stored, regardless of the data type, in 



only one way. In addition to the stored value the 
system then keeps up information indicating what type 
of data each memory location contains in order that 
data could be converted back to specific form. 

The storing in generic form can be implemented 
e.g by using the C++ template mechanism in such a way 
that there is an abstract base class called e.g. Value 
and several subclasses, one for each type that is 
stored in generic form. This is illustrated in figure 
4 for integer values, string values and for Boolean 
values. The following operations may be perfoormed on 
generic Value objects: (i) copy, (ii) store to a file, 
(iii) retrieve from a file, (iv) apply a test (where 
the test applied is one of the operations stored in 
AVAs). For performing the test, a subroutine called an 
ApplyTest Method is associated to each ValueMethods 
object. The ApplyTest Method performs the comparison 
between the generic values. Each ValueMethods object 
knows the type of the value of the attribute, i.e the 
type of the associated ApplyTest Method corresponds to 
that type . 

In order to find the value of an attribute by 
means of the object and the attribute identifier, the 
following two steps are undertaken. First, a checking 
is performed to see if the object has the attribute we 
are interested in. If the object does not have the 
attribute/ an error is reported at this stage. (The 
attribute may be defined either in the object or in 
one of its ancestors.) Secondly, a member pointer is 
combined, in a manner known as such, with the pointer 
to the object to find the value of the attribute. 
(This known meittber pointer, which is an offset into an 
object, is contained in the attribute identifier. When 
combined with a pointer to an object the member- 
pointer points to an individual data member or method 



of an object . ) 

ValueMethods objects perforin a number of 
operations for the attribute type. There is one 
ValueMethods object in the system for every supported 
type. For example there may be three String attributes 
in the system for a network element: name, 
manufacturer and physical location. These three 
attributes then all share a single String ValueMethods 
object . 

ValueMethods objects perform the following 
services in the system: 

a range of supported operations: the 
operations supported will depend on the attribute type 
that this ValueMethods object is managing. A String 
ValueMethods object would support isEqual, isNotEqual, 
startsWith, endsWith and contains; whereas an Integer 
ValueMethods object would support isEqual, isNotEqual, 
isGreaterThan, isLessThan, etc. 

- conversion of a value from a generic form to a 
specific data type. 

As mentioned above, all values in the 
management system are preferably held in a generic 
form. This generic form allows the system to store 
values without knowing their type. The generic form 
also provides an efficient way of implementing the 
test in which the logical operators stored in the 
filter are used. The ValueMethods object is able to 
convert from this generic type back to a specific 
type, for example from a generic representation of a 
String to a Specific String. 

To give an example, the name attribute 
introduced above contains a reference to a String 
ValueMethods object. The String ValueMethods object 
will support the following operations: 

- range of operations: isEqual, isNotequal, 



startWith, endsWith, contains. 

- conversion to String: a generic value can be 
converted to a string. 

As already mentioned, each AVA comprises an 
attribute, an operation and a value. The operation 
should be one of the operations supported by the 
ValueMethods object referenced by the attribute. If an 
illegal operation is used, e.g. a startWith operation 
on an Integer, the AVA will evaluate to False. The 
value stored in the AVA is held in generic format as 
mentioned above. This value will then be compared to 
the value of the specified attribute using the 
specified operator. (The comparison is made using said 
generic values.) To give an example, let us imagine 
that there is a need to find all network elements 
whose name begins with "SXC". The AVA for this purpose 
would be created with the following fields: 

- attribute: the Name attribute (as described in 
the above example) , 

- operation: startsWith, and 

- value: the generic representation of the 
string "SXC. 

Figure 6 illustrates evaluating a single AVA. 
First the attribute is fetched from the AVA (stage 
611) . Then, it is tested if the object has this 
attribute (612). If no, the result of the AVA is false 
(stage 619) . If yes, stage 613 is entered, where the 
ValueMethods object for the attribute in the object is 
searched for. After the ValueMethods object has been 
found, the ApplyTest Method of the ValueMethods object 
is called* Then it is tested (stage 615) if an 
ApplyTest Method of the correct type can be found. If 
the types of the ApplyTest Method found and the values 
to be compared are different, the AVA is false (stage 
619) . If an ApplyTest Method of the correct type was 



found, it is tested at the next stage whether the test 
succeeds. If yes, the AVA is true, if no, the AVA is 
false. The ApplyTest Method is a generic operation 
(comparing generic values) but at the same time a 
specific operation for the particular types of values 
that are compared with each other. 

In the following the method according to the 
present invention is illustrated by referring to the 
example of figures 7 and 8. In this example a filter 
is applied to an object which it matches (object 1, 
figure 7) and to one which it does not (object 2, 
figure 8) . Further, object 2 does not contain one of 
the attributes which the filter attempts to filter on. 

The filter stored at the selection point of the 
network is defined functionally as follows: 
(ExternalName, isEqual, "name-) AND (FaultState, 
isGreaterThan, 1) . This means that the filter asserts 
that the object has an attribute ExternalName which 
has a value of "name" and that the object also has an 
attribute FaultState which has a value greater than 
one. 

Object 1 is filtered as follows (figure 7): 

1 . Node A is evaluated which recursively 
evaluates its two child nodes. 

2. Node B is evaluated. 

2a. The value of the ExternalName attribute is 
extracted from object 1. 

2b. The operation isEgual is applied to the 
value "name" and the value obtained at stage 2a from 
object 1. This yields "True" as the two values are 
equal . 

3. Node C is evaluated. 

3a. The value of the FaultState attribute is 
extracted from object 1. 

3b. The operation isGreaterThan is applied to 



the value 1 and the value obtained at stage 3a from 
object 1, This yields True as 3 is greater than 1. 

4. The whole filter evaluates to (True AND True) 
which is True and the object is passed by the filter. 

Object 2 is filtered as follows (figure 8) : 

1. Node A is evaluated which recursively 
evaluates its two child nodes. 

2. Node B is evaluated. 

2a. The value of the ExternalNaine attribute is 
extracted from object 2. There is no ExternalName 
attribute so False is returned immediately. 

3. Node C is evaluated as (False AND anything) 
which is False, so the whole filter evaluates to 
False. Thus, the object is not passed by the filter. 

Though the invention has been described above 
referring to the example of the attached drawing, it 
is obvious that the invention is not restricted to 
that, but it can be modified in many ways within the 
scope of the inventive idea presented above and in the 
attached claims. As mentioned above, the management 
system includes a variety of objects, representing 
both logical and physical entities. In the enclosed 
claims all these objects are are set forth as "the 
objects that relate to the network elements to be 
managed", i.e. objects that represent the managed 
environment . 



Claims : 



1. A method for managing a telecommunications 
network, said telecommunications network comprising 
several network elements to be managed by the system, 

said system comprising a management centre 
having at least one workstation accomplishing a man- 
machine interface and allowing a manager to control 
the system, and the system being capable of providing 
the manager with information on the network, said at 
least one workstation being connected to a database 
including information about the managed network, said 
information being in the form of objects that relate 
to the network elements to be managed and in the form 
of references between the different objects, said 
references indicating the dependencies between the 
objects, whereby said management centre is connected 
to said network elements by data communication links 
such that the manager can initiate an operation on and 
receive information from a managed item of the 
network, in which method objects are selected at 
separate selection points of the system, characterized 
in that separate sets of data with logical operators 
linking the sets together are sent to a selection 
point of the system to be stored there, each set of 
data comprising an attribute identifier, a value- and 
an operation, and the selection is performed at the 
selection point so that an intermediate result is 
first derived for each set at the selection point by 

- using said attribute identifier to get the 
value of the same attribute from the object being 
selected, and 

- applying said operation to this value and the 
value stored at the selection point to obtain said 
intermediate result, and 



the intermediate results obtained are combined 
by Che stored logical operators to get a final result, 
and 

the final selection of the object is made on 
the basis of the final result. 

2. A method according to claim 1, cliaracterized 
in that the values of the attributes are stored in 
generic form which is independent of the data type in 
question. 

3 . A method according to claim 2 , cliaracterized 
in that said separate sets of data include a reference 
to an object which is able to (a) perform operations 
on the values of attributes generically, (b) convert 
said generic value back to a specific data type. 

4 . A method for managing a telecommunications 
network, said telecommunications network comprising 
several network elements to be managed by the system, 

said system comprising a management centre 
having at least one workstation accomplishing a man- 
machine interface and allowing a manager to control 
the system, and the system being capable of providing 
the manager with information on the network, said at 
least one workstation being connected to a database 
including information about the managed network, said 
information being in the form of objects that relate 
to the network elements to be managed and in the form 
of references between the different objects, said 
references indicating the dependencies between the 
objects, whereby said management centre is connected 
to said network elements by data communication links 
such that the manager can initiate an operation on and 
receive information from a managed item of the 
network, in which method events are filtered at 
separate filtering points of the system, characterized 
in that separate sets of data with logical operators 
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linking the sets together are sent to a filtering 
point of the system to be stored there, each set of 
data comprising an attribute identifier, a value and 
an operation, and the filtering is performed at the 
filtering point so that an intermediate result is 
first derived for each set at the filtering point by 

- using said attribute identifier to get the 
value of the same attribute from the event being 
filtered, and 

- applying said operation to this value and the 
value stored at the filtering point to obtain said 
intermediate result, and 

the intermediate results obtained are combined 
by the stored logical operators to get a final result, 
and 

the filtering of the event is made on the basis 
of the final result, 

5. A method according to claim 4, characterized 
in that the values of the attributes are stored in 
generic form which is independent of the data type in 
question, whereby said operation to said value and the 
value stored at the selection point is performed using 
said generic values • 

6. A method according to claim 4, characterized 
in that said separate sets of data include a reference 
to an object which is able to convert said generic 
value back to a specific data type. 

7. A method for managing a telecommunications 
network, substantially as hereinbefore described with 
reference to Figs 3 to 8 of the accompanying drawings- 
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